Fixed-Point ECU Development with Model-Based Design

When developing production software for fixed-point Engine Control Units (ECUs), it is important to consider the transition from floating-point to fixed-point algorithms. Systems engineers frequently design algorithms in floating-point math, usually double precision. This represents the ideal algorithm behavior without much concern for its final realization in production software and hardware. Software engineers and suppliers in mass production environments, however, are concerned with production realities and often need to convert these algorithms to fixed-point math for their integer-only hardware. A key task is to design scale factors that maximize code efficiency by minimizing the bytes used, while also minimizing quantization effects such that the fixed-point algorithms match the floating-point results within an acceptable numerical margin. This floatingto fixed-point conversion task is tedious, labor intensive, error-prone, and often requires multiple iterations between system and software engineers. Model-Based Design simplifies fixed-point development by providing tools and workflows that help the conversion process. System engineers doing on-target rapid prototyping for fixed-point ECUs often benefit from automated scaling and workflow assistance to support their initial fixed-point design. Production software engineers benefit from automated scaling as well, but they also require fine grain control over fixed data specification in their modeling environment to work with accumulator word sizes and target-specific optimizations. In addition to providing automated scaling and fine grain data modeling features, Model-Based Design capabilities for fixed-point verification and validation continue to evolve. One example is bitaccurate, fixed-point simulation with automated comparison to embedded software results using processor-in-the-loop testing. This paper presents Model-Based Design capabilities and tools that support development and verification of fixed-point ECU software used in mass production vehicles. INTRODUCTION Model-Based Design provides executable specifications, automatic code generation, and automated verification and validation tools. These technologies can be used to accelerate software development for any embedded system. Additional engineering effort is needed to produce the optimized designs and efficient code needed to satisfy the resource constraints of embedded microprocessors used in mass production. Thus, it is important to have processes and guidelines that yield optimal fixed-point code. This paper presents recently developed technologies and industry best practices for developing fixed-point code using Model-Based Design. The topics presented are: Developing the system model Preparing model and data for conversion Floatingto fixed-point conversion Generating optimized code Performing verification and validation DEVELOPING THE SYSTEM MODEL A case study based on a well-known fault tolerant fuel system demonstration model (shown in Figure 1) will help illustrate the development and verification of fixedpoint ECU software using Model-Based Design. Because this model has been described in previous literature [1], it will not be detailed here. However an overview is provided to explain the model structure and purpose. Figure 1: System model. The fuel control system model has three main components: a controller model for the ECU, a plant model for the engine gas dynamics, and several sensors. The engine model consists of air-fuel intake dynamics comprising both the throttle body and intake manifold. The engine model has two inputs, engine speed and throttle angle; and three outputs, sensed oxygen, manifold pressure (MAP), and air-fuel ratio. The plant model is developed using continuous time blocks. A 10 millisecond (10 ms) sample rate is required for the fuel rate control system algorithm. A closed-loop simulation can be performed using the plant and controller, plus input stimulus and output scopes. The controller must be tolerant to sensor failure faults. Faults can be inserted using manual switches. By toggling the input signals to nominal or fault values, model developers can examine the effect of the fault on controller performance and assess the controller’s tolerance to faults. The control system consists of a state machine and block diagrams. The state machine detects faults and establishes a fueling mode. Block diagrams model the sensor correction and fault redundancy logic, intake airflow estimation and correction logic, and a fuel rate calculation that concludes with a software limit on the fuel rate output command. The control system model is shown in Figure 2. Figure 2: Control system model. The control logic diagram has three states for each input sensor: warm up, normal, and failure. The criteria for transitioning between states are established via threshold parameters for each sensor. A sensor failure counter is used to track the total number of sensor failures. This counter is then used to determine a fueling mode. A low fueling mode is used if there are no sensor failures; a rich fueling mode is used for one sensor failure; and a disabled mode is used for two or more failures. Figure 3 shows the main portions of the state machine. Figure 3: Control logic state machine. The intake airflow estimation and correction logic shown in Figure 4 includes feedforward and feedback control algorithms. Table lookups provide pumping constants and rates. Figure 4: Closed-loop block diagram. The system model is then simulated and time response results are collected for metered fuel and air/fuel ratio as shown in figure 5. Figure 5: System response. This fuel system model is typical of most models initially developed using Model-Based Design. These models address the behavioral or functional requirements but are not necessarily well suited for implementation on an embedded system for a variety of reasons, such as: Continuous time representation of blocks is used instead of discrete. Simulation results are calculated using double precision real data types instead of integer or fixedpoint types. Interfaces between components such as the controller, plant, and sensors are not well specified or locked down. Some organizations try to address these issues by forcing the system developer to consider implementation aspects during initial algorithm design. In others, system designers are free to explore and optimize behavioral designs using their preferred modeling style. PREPARING MODEL AND DATA FOR CONVERSION After a floating-point behavioral model is developed, it must be prepared for implementation on a fixed-point embedded microcontroller. Some preparation tasks are needed even if the code is to be deployed code on a floating point processor. For example, the embedded system will run in discrete time, so continuous time blocks used for the embedded algorithm should be replaced by discrete blocks. It is possible to automate this process using conversion utilities. Rate transition blocks can also be used to convert the continuous-time signals to discrete-time signals sampled at 10ms, as required by the controller. Note that the effect of sampling on system performance and stability must also be analyzed. Preparing a model for conversion to fixed-point math requires several steps outlined in the following sections. CREATE INITIAL REFERENCE DATA Before beginning any model conversion task, create reference signal data for your floating point, behavioral model. These results can be used later for equivalence comparisons with the fixed-point model and generated code. The results shown in Figure 5, for example, will be used for equivalence testing of the fuel system controller. REPLACE UNSUPPORTED BLOCKS Identify and replace blocks that do not support fixedpoint types. This includes replacing continuous-time with discrete-time blocks. Start by reviewing a list of data types supported by each block, as shown in Figure 6. For models with Embedded MATLAB® functions, choose those that support fixed-point. There are hundreds of functions and blocks that support fixed-point implementation, including all the functions an engineer would typically use in embedded algorithm design. Figure 6: Block data type support table. SET UP SIGNAL LOGGING Logging signals of interest during simulation is important because logged signals are used for analysis and comparison in other tasks. Model inputs and outputs are commonly logged (as was done with the initial reference data) but it may be helpful to log other signals to help with conversion to fixed-point. Engineers no longer need to specifically add blocks or name signals to log data. It is now possible to log unnamed signals or log all data from a selected portion of the model subsystem hierarchy as shown in Figure 7. Figure 7: Logging fixed-point data. SPECIFY TARGET HARDWARE CHARACTERISTICS The model simulation behavior and code generation outputs are determined by target hardware characteristics. Specifying the correct word lengths for char, int, long, and other attributes unique to a particular embedded microprocessor is needed to avoid producing incorrect results during simulation or code generation. CHECK MODEL SUITABILITY FOR PRODUCTION Automated model checks should be used to inspect the model’s suitability for production code deployment as shown in Figure 8. These checks cover a broad range of topics such as model upgrades and library links. Some checks, such as “identify questionable fixed-point operations” and “check hardware implementation”, are crucial for fixed-point development. Additional checks can be run, including checks based on the updated MAAB guidelines [2] or safety related standards such as IEC 61508 [3]. Figure 8: Model checks can determine a model’s suitability for